@MarcoGorelli I took a try at your idea of typehinting the whole set of arguments in pd.DataFrame.query but stumbling upon the issue when the user passes a dictionary (which is still an allowed behavior).
Wondering if there is something I am missing here, please let me know!

You'd still need to have the **kwargs as an overload. If you want to allow the other arguments, you can have that (although I don't think we should do that because it's not documented), but you'd still need the **kwargs overload

I was able to make some progress here, let me know if this is what you envisioned and I will clean it up.

Hey - yeah, this is what I was thinking - I don't really understand why **kwargs would be needed at all, given that the accepted arguments by eval are limited https://pandas.pydata.org/docs/reference/api/pandas.eval.html#pandas.eval , although based on

If you want to allow the other arguments, you can have that (although I don't think we should do that because it's not documented)

it looks like Irv disagrees and that what I've suggested may be against the pandas-stubs philosophy - which is fair enough

Hey - yeah, this is what I was thinking - I don't really understand why **kwargs would be needed at all, given that the accepted arguments by eval are limited https://pandas.pydata.org/docs/reference/api/pandas.eval.html#pandas.eval , although based on

If you want to allow the other arguments, you can have that (although I don't think we should do that because it's not documented)

it looks like Irv disagrees and that what I've suggested may be against the pandas-stubs philosophy - which is fair enough

So I looked more carefully at the pandas docs, which do say that the accepted **kwargs are from eval(). Not the greatest on the docs front, and that could be improved. Maybe one of you could create an issue there??

So I'll look more carefully at this PR now with that in mind.

I will raise an issue on the pandas side if it is not simpler to have all the arguments directly in the function. It is a good point since it should not be too hard to maintain.

I will raise an issue on the pandas side if it is not simpler to have all the arguments directly in the function. It is a good point since it should not be too hard to maintain.

It's a docs issue, so raise an issue there that it would be more useful to list the arguments under query() rather than have people have to click on eval()

Opened the issue on pandas repo, will mark this PR as blocked for now until the pandas team can clarify orientation on this.

Opened the issue on pandas repo, will mark this PR as blocked for now until the pandas team can clarify orientation on this.

I think we should remove the kwargs from the stubs. The docs do say that the only valid kwargs are the ones from eval(), so let's just include them. If we get complaints, we point them to that part of the docs.